Software for connecting information, people, systems, and devices such as Microsoft .NET (.NET) provides Extensible Markup Language (XML) based interoperability and is currently being incorporated across clients, servers, services, and tools. For example, products like Microsoft Windows® and Microsoft Office® will use .NET to connect with other systems and applications. For software developers, .NET is manifested in the programming model delivered in the Microsoft®.NET Framework. This framework is an integral Microsoft Windows® component that enables building and running the next generation of software applications and World Wide Web (Web) services. It includes technologies for Web services and Web applications, data access, smart client applications and many others.
As the .NET development community grows, the number of host applications, both Component Object Model (COM) based as well as .NET based, that wish to integrate automation models will grow. Moving forward, patterns have been established of using Managed Add-in Framework (MAF) for that integration. The MAF defines a programming model, built on top of .NET that allows applications to dynamically load and communicate with generic components at runtime. However, getting existing host applications to conform to the model required by the MAF would require a great deal of work on the part of the host integrator, potentially even forcing a rewrite of significant portions of the application itself.
Currently, there exists a minimal set of tools that allow COM host applications to generate wrappers that managed code can directly interact with. These tools are extremely limited and provide little ability for the user to correct, modify, add, and/or remove functionality that better serves the .NET developer community. Both COM and .NET host applications are also limited by the fact that they cannot generate wrappers that conform to the requirements of the Managed Add-in Framework (MAF).
Also allowing for hosts to create managed views of their COM automation models is problematic with respect to customizing the output. Historically, tools like type library importer (TLBIMP) have been used. However, TLBIMP produces a .NET assembly as its output which means that the integrator does not have an opportunity to customize the output. If this is a requirement for the integrator, they would then be forced to hand write their interop assembly or disassemble the output assembly, tweak the intermediate language (IL), and then reassemble the modified IL. Both of these options are quite expensive and can lead to further issues
Thus, needed are processes and a system that addresses the shortcomings of the prior art.